1. Field of the Invention
This invention relates to a method and apparatus for selecting a service binding protocol in a service-oriented architecture in which a client invokes a service from a service provider using a selected transport binding. More particularly, it relates to a method and apparatus for selecting such a service binding protocol through negotiation and diagnosis.
2. Description of the Related Art
Reference may be made in this specification (using bracketed numbers) to the Publications listed in Appendix B, available either in printed form or online and incorporated herein by reference.
One of the more significant events in the field of information technology in the last several years has been the development of specifications and implementations of Web services and its close kin, Grid services. As described in reference [2] at page 7, “Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. Web services perform encapsulated business functions, ranging from simple request-reply to full business process interactions.” Web services have been codified in such standards specifications as the Web Services Description Language (WSDL) [1]. Grid services [10, 11] have been defined as Web services that conform to a set of conventions (interfaces and behaviors) that define how a client interacts with a grid service. Grid services have been used to create virtual organizations (VOs) in which available computing resources (applications, processors, etc.) that are actually located remotely appear as local resources to a user.
In a service-oriented architecture such as Web services, a service provider can provide a number of transport protocols used for binding to access a service. This is done in order to provide better quality-of-service (QOS) features for the clients. One example of this binding is a transport binding for a service using IIOP instead of SOAP/HTTP for better performance. (For these and other acronyms, see the glossary in Appendix A below. SOAP is described in more detail in references 3-6 and 12 of Appendix B.) The service provider defines this binding information in a WSDL document at the time of the service deployment and initiates the server-side framework (stubs/JMS listener etc.) to support those bindings. The service skeletons are created to handle incoming requests in a binding-specific manner and convert the incoming requests to the platform-specific service invocation model. There can be a number of binding protocol models (SOAP/HTTP, IPC, IIOP, RMI, SOAP/JMS etc.) that can be created based on such criteria as performance, interoperability, service container capabilities and QOS requirements. The client who uses the service can get hold of the WSDL document for the service from some registries (UDDI) or from the service itself (through HTTP GET) and evaluate the WSDL document. The client can generate static stubs or can dynamically introspect the WSDL document for the service invocation. This results in a client with a number of transport-protocol binding information proxies, from which the client needs to select one to invoke the service.
FIG. 1 is a concept map showing the relationships between a client 102, a service 104 (also referred to herein as a “service provider”), various bindings 106, and a WSDL document 108. As shown in the figure, a client 102 uses the WSDL document 108 to generate a service binding 106, and the client 102 invokes the service 104 (by issuing a service request) using the generated binding 106. Service 104 in turn uses the selected binding 106.
As shown in FIG. 1, now the client faces a major problem about which binding to select to achieve the QOS characteristics it needs. The service provider assumes that the client is capable of making intelligent decisions on the protocol binding selection based on its needs on QOS requirements such as performance and throughput, platform capability and configuration. Today, this approach can provide some static information models and binding selection preferences through WSDL extensions and binding ordering. But for a client this is not enough to make intelligent decisions on binding selection.
There are current efforts to provide a client with a more elaborate information model on the service protocol binding. Thus, a client can select a binding based on (1) WSDL binding extensibility information and binding selection policies (service level agreements and policies); (2) client configuration and deployment policies, including static deployment options and service level agreement (SLA) requirements as well as dynamic polices and SLA requirements (programming model configuration, policies etc); (3) machine-interpretable semantic information associated with the client through WSDL extensions for RDF; and (4) automatically imposed binding rules like order of binding. Additionally, or alternatively, this may be effected through service provider policies such as service-provided deployment policies (e.g., expose only certain bindings at some point in time) or having a server provide polices through SLA, UDDI etc.
These efforts, however, are merely extensions to the existing WSDL description and programming model and do not address the dynamic configuration needs for a client at runtime through a dynamic handshaking (negotiation) process. Similarly, WSIF (Web Service Invocation Framework) is a framework provided to create a multi-binding channel at the client side based on the static information from the WSDL files.
Also, there are several problems with the solutions mentioned above. They require a prior knowledge of the transport binding selection on the client and server side. Most of the requirements for QOS must be known beforehand and need to be configured before service invocation. They are very static in nature, with little flexibility. They depend on a number of tools, based on the different service provider requirements. Their ability to support intermediaries is very limited, as is their ability to dynamically change a binding for some specific QOS requirement. Finally, they are not able to enter into a conversation with the server on transport binding selection, which would result in better QOS controls.
What is needed, therefore, is a mechanism for a dynamic transport binding selection.